home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940277.txt < prev    next >
Text File  |  1994-11-13  |  22KB  |  561 lines
  1. Date: Fri, 19 Aug 94 04:30:21 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #277
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Fri, 19 Aug 94       Volume 94 : Issue  277
  11.  
  12. Today's Topics:
  13.                                 (none)
  14.            ??can u use internet to 2 mtr. packet? (2 msgs)
  15.                          A message from micah
  16.                           Baypac and HTX-202
  17.                    Internet Connections Via Packet
  18.                             Is there a FAQ
  19.                           JVFAX Interfaces?
  20.                     Kantronics KPC-3 or MFJ 1270C?
  21.                 Need 9600 baud mod info for IC271/471
  22.                     New satellite Windows programs
  23.                             Upgrading TNC
  24.                  Widrow-Hoff LMS algorithm for DSP???
  25.                               X1J Gurus?
  26.  
  27. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  28. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  29. Problems you can't solve otherwise to brian@ucsd.edu.
  30.  
  31. Archives of past issues of the Ham-Digital Digest are available 
  32. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  33.  
  34. We trust that readers are intelligent enough to realize that all text
  35. herein consists of personal comments and does not represent the official
  36. policies or positions of any party.  Your mileage may vary.  So there.
  37. ----------------------------------------------------------------------
  38.  
  39. Date: 19 Aug 94 19:19:01 GMT
  40. From: news-mail-gateway@ucsd.edu
  41. Subject: (none)
  42. To: ham-digital@ucsd.edu
  43.  
  44. 
  45.  
  46. ------------------------------
  47.  
  48. Date: Tue, 16 Aug 1994 22:15:54 GMT
  49. From: ihnp4.ucsd.edu!newshub.sdsu.edu!nic-nac.CSU.net!usc!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!news.ucdavis.edu!chip.ucdavis.edu!szhall@network.ucsd.edu
  50. Subject: ??can u use internet to 2 mtr. packet?
  51. To: ham-digital@ucsd.edu
  52.  
  53.   Can a person send a message from internet to 2 meter packet radio..I 
  54. sure this been asked before.  Also can you send a 2 meter packet msg. to 
  55. internet?..Jeff
  56.  
  57. ------------------------------
  58.  
  59. Date: Wed, 17 Aug 1994 10:11:03 GMT
  60. From: ihnp4.ucsd.edu!ucsnews!newshub.sdsu.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!ka4byp@network.ucsd.edu
  61. Subject: ??can u use internet to 2 mtr. packet?
  62. To: ham-digital@ucsd.edu
  63.  
  64. szhall@chip.ucdavis.edu wrote:
  65. :   Can a person send a message from internet to 2 meter packet radio..I 
  66. : sure this been asked before.  Also can you send a 2 meter packet msg. to 
  67. : internet?..Jeff
  68.  
  69. Its done all the time, but there's no guarantee that the message will get 
  70. thru unless the gateway station is *well* connected and maintained.  And 
  71. that appropriate routing and paths are available  to and from stations 
  72. (BBS's) beyond the gateway machine.   73/bob ka4byp
  73.  
  74.  
  75. -- 
  76. *******
  77. Bob Merritt  KA4BYP  ----->  ka4byp@netcom.com  <-----
  78.  
  79. ------------------------------
  80.  
  81. Date: 17 Aug 1994 23:13:39 -0700
  82. From: solano.community.net!odin.community.net!not-for-mail@uunet.uu.net
  83. Subject: A message from micah
  84. To: ham-digital@ucsd.edu
  85.  
  86.     When I origanaly posted my first message on this news groupe I 
  87. diddn't anticipate such an onslought of replies, I was not flamed (thank 
  88. goodness) but I did receive quite a few non the less.
  89.  
  90.     Most of them were supportive of my actions but cutioned me on how 
  91. big of messages to send throught the net. The rest were unsupportive to 
  92. say the least.
  93.  
  94.     I feal that I stirred up a small controversy in this news groupe.
  95.  
  96.     I ownly do my packetting in the wee hours in the morning (from 00 - 
  97. 0500pac), due to the high packet use through out the day in my area, any 
  98. thing below 25watts has no chance at a decent connection ( I run packet 
  99. on my HT). I ownly do my BBSen on the wa6ham bbs in pittsburg cal. I like to set a goal on how far 
  100. I can go on the net in a single night. so far colorado springs is the 
  101. farthest west I've gotten, I'm trying to get back to St. Joesepg mo. I 
  102. have family there.
  103.  
  104. -Micah-
  105. KD6PJM
  106.  
  107. ------------------------------
  108.  
  109. Date: Tue, 16 Aug 1994 15:04:52 AST
  110. From: dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!charnel.ecst.csuchico.edu!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston.ans.@ihnp4.ucsd.edu
  111. Subject: Baypac and HTX-202
  112. To: ham-digital@ucsd.edu
  113.  
  114. Please tell me the configuration of the baypac modem and the Radio Shack 
  115. 2 meter.
  116.  
  117. Thanks Paul VE9VW.
  118.  
  119. ------------------------------
  120.  
  121. Date: 18 Aug 1994 07:08:16 GMT
  122. From: ihnp4.ucsd.edu!munnari.oz.au!sgiblab!rpal.rockwell.com!headwall.Stanford.EDU!leland.Stanford.EDU!gekko@network.ucsd.edu
  123. Subject: Internet Connections Via Packet
  124. To: ham-digital@ucsd.edu
  125.  
  126. Currently I'm involved in a project requiring constant access to internet
  127. anywhere in the United States.  I know almost nothing about packet radio, but
  128. someone said such access may be possible with packet radio.  Is this possible? 
  129. If so, how much slower and unreliable is it?
  130.  
  131. I couldn't find an FAQ... so if this is a very common question, sorry!
  132.  
  133. John 
  134. gekko@leland.stanford.edu
  135.  
  136. ------------------------------
  137.  
  138. Date: Tue, 16 Aug 94 22:35:10 GMT
  139. From: ihnp4.ucsd.edu!newshub.sdsu.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!yeshua.marcam.com!zip.eecs.umich.edu!panix!198!mgalatz@network.ucsd.edu
  140. Subject: Is there a FAQ
  141. To: ham-digital@ucsd.edu
  142.  
  143. Hi everyone,
  144.  
  145. Is there a FAQ about radios and digital com?
  146.  
  147. ------------------------------
  148.  
  149. Date: 18 Aug 1994 01:28:10 GMT
  150. From: dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!charnel.ecst.csuchico.edu!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston.ans.@ihnp4.ucsd.edu
  151. Subject: JVFAX Interfaces?
  152. To: ham-digital@ucsd.edu
  153.  
  154. Mike Cowgill (zeus@myth.demon.co.uk) wrote:
  155. :  I am currently running JVFAX 5.1 (anyone know a FTP site for a more recent 
  156. : version?) with the simple comparator interface. Before I launch head on into 
  157. : building the full AM/FM serial port version, are there any plans to use the 
  158. : Sound Blaster ADC?, or are there any alternative circuits, since the ADC chip 
  159. : is proving difficult to source. Cheers.
  160.  
  161. : Mike.
  162.  
  163. : -- 
  164.  
  165. :  Michael S. Cowgill (Mike)        \_ My opinions!  MINEMINEALLMINEHAHAHAHA!
  166. :  zeus@myth.demon.co.uk (That's me) \_       " Swirly thing alert! "
  167. :  G1VOX@GB7WRG.GBR.EU 44.131.2.76    \_ "  ...Cracking toast Gromit!... "
  168.  
  169.  
  170. A new version (6.0) of JVFAX can be found in the FTP sites listed
  171. below.
  172.  
  173.  
  174. Host plaza.aarnet.edu.au   (139.130.4.6)
  175. Last updated 14:13 27 Feb 1994
  176.  
  177.     Location: /micros/pc/oak/hamradio
  178.       FILE      r--r--r--    506282  Nov  9 02:38   jvfax60.zip
  179.  
  180. Host pc.usl.edu   (130.70.40.3)
  181. Last updated 07:19 21 Feb 1994
  182.  
  183.     Location: /pub/ham
  184.       FILE      rw-r--r--    506282  Nov 24 22:04   jvfax60.zip
  185.  
  186. Host nctuccca.edu.tw   (192.83.166.10)
  187. Last updated 04:12  2 Mar 1994
  188.  
  189.     Location: /PC/fidonet/ham/hamcomm
  190.       FILE      r--r--r--    533929  Feb 25  1994   jvfax601.zip
  191.  
  192. -------
  193.  
  194. ------------------------------
  195.  
  196. Date: 17 Aug 1994 18:06:39 GMT
  197. From: ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!lll-winken.llnl.gov!earl.llnl.gov!user@network.ucsd.edu
  198. Subject: Kantronics KPC-3 or MFJ 1270C?
  199. To: ham-digital@ucsd.edu
  200.  
  201. Greetings,
  202. I am looking into getting into packet and was looking for input as to a
  203. preference between the Kantronics KPC-3 and the MFJ 1270C (or another TNC I
  204. should consider)?
  205. My use will be VHF packet using a Mac and an IC-2AT.
  206.  
  207. Thanks in advance,
  208. Gary KE6KXL (Kilowatt X-ray Laser)
  209.  
  210. ---------------------------------------------------------------------------
  211.    The ramblings expressed above do not reflect the opinions of LLNL.
  212.  
  213.    Gary Ross                                         Ross@NOVAX.LLNL.GOV
  214.    Lawrence Livermore National Laboratory            Rossman@eworld.com    
  215.  
  216.    NOVA Laser Operations                             Rossman@aol.com
  217.    P.O. Box 808, L-489                             
  218.    Livermore, CA 94551                             
  219.  
  220.  
  221.                              
  222.    
  223.   
  224.  
  225. ------------------------------
  226.  
  227. Date: Thu, 18 Aug 94 13:33:11 PDT
  228. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.kei.com!ssd.intel.com!chnews!news@network.ucsd.edu
  229. Subject: Need 9600 baud mod info for IC271/471
  230. To: ham-digital@ucsd.edu
  231.  
  232. Im looking for 9600 baud modification info for the ICOM 271 & 471.
  233.  
  234. Thanks & 73s,
  235. Tom WB7ASR...
  236.  
  237. ------------------------------
  238.  
  239. Date: Thu, 18 Aug 94 13:10:16 PDT
  240. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.kei.com!ssd.intel.com!chnews!news@network.ucsd.edu
  241. Subject: New satellite Windows programs
  242. To: ham-digital@ucsd.edu
  243.  
  244. I just received my copy of the July/August 1994 issue of THE AMSAT JOURNAL.
  245. In the journal, pages 6-9, they talk about a new Windows PB and PG like
  246. program by ZL2TPO. The program also has a fully intergrated color graphic 
  247. world map showing satallite positions and foot prints. It has full support 
  248. for the Kansas City Tracker/Tuner, with the optional Windows program by 
  249. KC6WYG, on page 10.
  250.  
  251. Both programs can be purchased from AMSAT direct for $40.00 @ 301-589-6062
  252. All proceeds go to the Phase3D program. 
  253.  
  254. 73s, Tom WB7ASR...
  255.  
  256. ------------------------------
  257.  
  258. Date: 18 Aug 94 13:10:22 GMT
  259. From: news-mail-gateway@ucsd.edu
  260. Subject: Upgrading TNC
  261. To: ham-digital@ucsd.edu
  262.  
  263. >I currently use a Baycom BP-1 on a 8088 PC.  Being that I am only doing
  264. >packet, what advantages would I have upgrading to a more expensive TNC
  265.  
  266. basically, a separate hardware TNC is better at being a TNC than the software 
  267. TNCs in several respects. it comes down to being able to use the computer for 
  268. something else and still have the TNC function available...in some cases you 
  269. get added functionality since the TNC could have a mini-mailbox in it and the 
  270. TNC could be left on to be a digipeater for other stations and such.
  271.  
  272. the software TNC is attractive in that changes to things can be easily (??) 
  273. done since "it's only software." (famous last words...)
  274.  
  275. several of the guys here built up the "PMP" style packet boxes and in the end 
  276. we really want a real TNC we can hang on a terminal server so we can run 
  277. packet from the desk at break time...8)
  278.  
  279. hopefully we'll make enough bucks this year at the hamfest to swing something 
  280. like an MFJ-1248 or whatever the model number is...maybe even a radio to go 
  281. with it...
  282.  
  283. 73, bill wb9ivr
  284. collins amateur radio club/melbourne, fl
  285.  
  286. ------------------------------
  287.  
  288. Date: Mon, 15 Aug 1994 01:25:06 GMT
  289. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!hookup!reptiles.org!geac!torsqnt!problem!vigard!mdf@network.ucsd.edu
  290. Subject: Widrow-Hoff LMS algorithm for DSP???
  291. To: ham-digital@ucsd.edu
  292.  
  293. ahall@ux4.cso.uiuc.edu (Allen Hall) writes:
  294. >Appearantly the LMS algorithm is nice to use to cut out signals that
  295. >are repetetive when listening to SSB (you wouldn't use it for CW-cause
  296. >all you would hear instead of the morse code was a "click" evertime
  297. >a new tone came buy :)
  298.  
  299. it also works the other way around:  you can use it to pick out the
  300. repetitive (correlated) signals, and remove the random (uncorrelated) ones.
  301.  
  302. the algorithm is frighteningly simple, and most textbooks on signal
  303. processing will contain a discussion of it.  further information should
  304. be found in such a place, and not the network.  try a library.
  305.  
  306. but for those impatient folk with Linux machines and sound card, what follows
  307. is a very small and very simple piece of demo code that runs an LMS on
  308. /dev/dsp output.  it is disgustingly inefficient (too many ops/sample,
  309. use of double's etc), so only runs at about 1/4 real-time rate (8000
  310. samples/second) if you have a 33MHz 486 and have cached the sample file.
  311.  
  312. usage is simple: grab a sample from /dev/dsp into some file:  "cat
  313. /dev/dsp >blee".  then "./lms <blee >/dev/dsp", or write the output to
  314. another file and blat that into /dev/dsp to listen to it without the
  315. gaps.  "lms -c" removes correlated signals [which is what heterodyne
  316. supression filtering does] and "lms -n" removes uncorrelated signals.
  317.  
  318. as simple as this is, it does a *remarkably* effective job.
  319. ---- begin lms.c ----
  320. #include <stdio.h>
  321. #include <math.h>
  322. #include <stdlib.h>
  323.  
  324. double    xb[4096];
  325. double     w[1024];
  326. #define    XMASK    0x3ff
  327.  
  328. int    mode;
  329. #define    NO_UNCOR 0
  330. #define    NO_COR   1
  331.  
  332. extern    int    optind;
  333. extern    char    *optarg;
  334.  
  335. int
  336. main(int argc, char **argv)
  337. {
  338.     double    x, b, p, v, g, e, levl;
  339.     int    M, n, c, i, delay;
  340.  
  341.     mode = NO_UNCOR;
  342.     b     = 0.99;
  343.     M     =   32;
  344.     delay =   32;
  345.     n     = 2028;
  346.     levl  =  1.0;
  347.     while((c = getopt(argc, argv, "a:M:D:b:nc")) != EOF) {
  348.         switch(c) {
  349.         case    'n': mode = NO_UNCOR;        break;
  350.         case    'c': mode = NO_COR;           break;
  351.         case    'M': M = atoi(optarg);        break;
  352.         case    'D': delay = atoi(optarg);    break;
  353.         case    'b': b = atof(optarg);        break;
  354.         case    'a': levl = atof(optarg);    break;
  355.         }
  356.     }
  357.  
  358.     for(i=0; i<M; ++i)
  359.         w[i] = 1.0;
  360.     p = 0.00;
  361.     while((c = getchar()) != EOF) {
  362.         xb[n&XMASK] = x = ((double) c) - 128.0;
  363.         p = b*p + (1.0 - b)*x*x;
  364.         if(p == 0.0)
  365.             v = 1.0;
  366.         else
  367.             v = (1.0 - b)/p;
  368.         g = 0;
  369.         for(i=0; i<M; ++i)
  370.             g += w[i]*xb[(n-delay-i)&XMASK];
  371.         v *= x - g;
  372.         for(i=0; i<M; ++i)
  373.             w[i] += v*xb[(n-delay-i)&XMASK];
  374.         ++n;
  375.  
  376.         /*
  377.          * new signal output
  378.          */
  379.         if(mode == NO_COR)
  380.             g = x - g;
  381.         g *= levl;
  382.         putchar(128 + (int) g);
  383.     }
  384. }
  385. ---- end lms.c ----
  386. -- 
  387. Matthew Francey                     mdf@vigard.mef.org            ve3rqx@io.org
  388. "live before you die"               GPS(NAD27): N43o34.210' W079o34.563' +0093m
  389.  
  390. ------------------------------
  391.  
  392. Date: 18 Aug 1994 02:28:13 GMT
  393. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@network.ucsd.edu
  394. Subject: X1J Gurus?
  395. To: ham-digital@ucsd.edu
  396.  
  397. In a previous article, mfoster.amoco.com (Michael H. Foster) says:
  398.  
  399. >Has anyone optimized their x1j parms?
  400. >With several band openings over the past few weeks, the x1j's locally
  401. >lose their buffer space and hose up until a reset is given.  We are 
  402. >trying different parm settings hoping the node will release it's buffer
  403. >space faster, but we have no specific parameter documentation to guide us with these settings.
  404. >Can anyone provide any insight or specifics? 
  405. >
  406.  
  407. One of the best things to do is lock in the nearest neighbor routes and
  408. set the port QUALITY to 1.  That way, all nodes except for the ones that 
  409. you have locked in the local ROUTES table will be ignored.  Even tho the
  410. band is open, you don't want all of those temporary paths reported.
  411.  
  412. The change in the PARAMs list  is the second or third one; radio port
  413. quality.  Once you lock the routes, you can change the 192 to 1.
  414.  
  415. In this area, there are about 10 digi's that can be heard on 144.91 when the
  416. band opens.  The locked routes keeps the network sane.
  417.  
  418. By the way, if you are running BPQ at your local BBS or DXcluster, it should
  419. also be locked to only the nearest neighbor TheNet nodes.
  420.  
  421. 73, Drew
  422.  
  423.  
  424. -- 
  425. *-----------------------------*-------------------------------------*
  426. |    Andrew B. White  K9CW    |    internet: k9cw@prairienet.org    |
  427. |    ABW Associates, Ltd.     |   phone/fax: 217-643-7327           |
  428. *-----------------------------*-------------------------------------*
  429.  
  430. ------------------------------
  431.  
  432. Date: Thu, 18 Aug 1994 20:08:51 GMT
  433. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!newshub.nosc.mil!news@network.ucsd.edu
  434. To: ham-digital@ucsd.edu
  435.  
  436. References <32b56i$ot5@Tut.MsState.Edu>, <32d90d$2gg@vixen.cso.ui, <3306v8$jbi@vixen.cso.uiuc.edu>
  437. Reply-To : craigr@marlin.nosc.mil
  438. Subject : Re: Looking for DXCluster software
  439.  
  440. In <3306v8$jbi@vixen.cso.uiuc.edu>, k9cw@prairienet.org (Andrew B. White) writes:
  441. >
  442. >In a previous article, gary@ke4zv.atl.ga.us (Gary Coffman) says:
  443. >
  444. >>Yes, $400 is excessive. It's excessive because cluster is such a bandwidth
  445. >>wasting kludge. (Ok, it's a *useful* kludge, but kludge it is.) You can
  446. >>use free broadcast server software sending the info *2* times, one uplink
  447. >>and one broadcast (Pacsat protocol), instead of *27* to accomplish the 
  448. >>same DX spot reporting. That's much more bandwidth friendly. Fills can be 
  449.  
  450.  
  451. >While I agree with you that PC use of AX.25 is not the best for distributing
  452. >spots, it is, currently, the only game in town.  AK1A has something like
  453. >400 nodes installed around the world, and they all talk to each other (altho
  454. >the email facility comes close to being useless if the mail has to go more
  455. >than one hop).  Besides, if the network is configured as it should be,
  456. >with local users on one frequency and the inter-node link on another, I
  457. >am not sure that the amount of bandwidth required is an issue.
  458.  
  459. I also agree that AX.25 is not the best protocol for sending DX spots but 
  460. PacketCluster is an AX.25 application that requires the minimum equipment
  461. on the user end.  A radio, TNC, and dumb terminal is the user investment. It
  462. would seem that to implement a more efficient protocol would certainly require
  463. a computer on the user end to sort things out.  Some of the OF's barely mastered
  464. getting a dumb terminal to talk to a TNC, it would be real interesting watching
  465. them trying to become computer literate. Hi..
  466.  
  467. But if someone came out with a system that offered enough advantages over the
  468. current Cluster software, I think it might catch on. There are many problems
  469. with PC that could be overcome by a more robust protocol which would be very 
  470. attractive to the sysops.  My own feeling is that PacketCluster needs competition
  471. or many of the problems with it are not going to be solved.
  472.  
  473. Rick Craig, N6ND
  474. craigr@marlin.nosc.mil
  475.  
  476. ------------------------------
  477.  
  478. Date: 18 Aug 1994 17:49:28 GMT
  479. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@network.ucsd.edu
  480. To: ham-digital@ucsd.edu
  481.  
  482. References <119955@cup.portal.com>, <32b56i$ot5@Tut.MsState.Edu>, <32d90d$2gg@vixen.cso.ui
  483. Reply-To : k9cw@prairienet.org (Andrew B. White)
  484. Subject : Re: Looking for DXCluster software
  485.  
  486.  
  487. In a previous article, gary@ke4zv.atl.ga.us (Gary Coffman) says:
  488.  
  489. >Yes, $400 is excessive. It's excessive because cluster is such a bandwidth
  490. >wasting kludge. (Ok, it's a *useful* kludge, but kludge it is.) You can
  491. >use free broadcast server software sending the info *2* times, one uplink
  492. >and one broadcast (Pacsat protocol), instead of *27* to accomplish the 
  493. >same DX spot reporting. That's much more bandwidth friendly. Fills can be 
  494. >requested by user stations if a packet is missed, but that should take up 
  495. >lots less bandwidth than repeating the same data over and over and over to 
  496. >each and every connected station as cluster does.
  497. >
  498. While I agree with you that PC use of AX.25 is not the best for distributing
  499. spots, it is, currently, the only game in town.  AK1A has something like
  500. 400 nodes installed around the world, and they all talk to each other (altho
  501. the email facility comes close to being useless if the mail has to go more
  502. than one hop).  Besides, if the network is configured as it should be,
  503. with local users on one frequency and the inter-node link on another, I
  504. am not sure that the amount of bandwidth required is an issue.
  505.  
  506. CW uses quite a bit less bandwidth than SSB, but I don't think you would
  507. advocate abandoning phone...
  508.  
  509. 73, Drew
  510.  
  511.  
  512. -- 
  513. *-----------------------------*-------------------------------------*
  514. |    Andrew B. White  K9CW    |    internet: k9cw@prairienet.org    |
  515. |    ABW Associates, Ltd.     |   phone/fax: 217-643-7327           |
  516. *-----------------------------*-------------------------------------*
  517.  
  518. ------------------------------
  519.  
  520. Date: Thu, 18 Aug 1994 14:47:06 GMT
  521. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!swrinde!emory!wa4mei!ke4zv!gary@network.ucsd.edu
  522. To: ham-digital@ucsd.edu
  523.  
  524. References <32b56i$ot5@Tut.MsState.Edu>, <32d90d$2gg@vixen.cso.uiuc.edu>, <32ugib$m02@vixen.cso.uiuc.edu>│▒
  525. Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman)
  526. Subject : Re: Looking for DXCluster software
  527.  
  528. In article <32ugib$m02@vixen.cso.uiuc.edu> k9cw@prairienet.org (Andrew B. White) writes:
  529. >
  530. >Is $400 really excessive?  If you own a modern transceiver, you paid much
  531. >more than that for it (new).  Add an antenna, amp, keyer, computer, etc,
  532. >there is quite a bit tied up in this hobby.  If there is interest in DX
  533. >operation in your area, you should be able to find local support for the
  534. >cluster.  Here in Central IL, we have fewer than two dozen hams who play the
  535. >DX game, but all are willing to support the Cluster.  I suggest that you
  536. >ask around - you might be surprised to find that there are, indeed, people
  537. >willing to pay money for access to timely DX spots! 
  538.  
  539. Yes, $400 is excessive. It's excessive because cluster is such a bandwidth
  540. wasting kludge. (Ok, it's a *useful* kludge, but kludge it is.) You can
  541. use free broadcast server software sending the info *2* times, one uplink
  542. and one broadcast (Pacsat protocol), instead of *27* to accomplish the 
  543. same DX spot reporting. That's much more bandwidth friendly. Fills can be 
  544. requested by user stations if a packet is missed, but that should take up 
  545. lots less bandwidth than repeating the same data over and over and over to 
  546. each and every connected station as cluster does.
  547.  
  548. I know, think of it as *test* data for the network engineers. :-(
  549.  
  550. Gary
  551. -- 
  552. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  553. Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
  554. 534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
  555. Lawrenceville, GA 30244     |                     | gary@ke4zv.atl.ga.us
  556.  
  557. ------------------------------
  558.  
  559. End of Ham-Digital Digest V94 #277
  560. ******************************
  561.